Using smartcards or other cryptographic modules for enabling connected devices to access encrypted audio and visual content

ABSTRACT

To prevent piracy, audiovisual content is encrypted prior to transmission to consumers. A low-cost, high-security cryptographic rights module (such as a smartcard) enables devices such as players/displays to decode such content. Security-critical functions may be performed by the cryptographic module in a manner that allows security compromises to be addressed by upgrading or replacing cryptographic modules, thereby avoiding the need to replace or modify other (typically much higher-cost) components. The security module contains cryptographic keys, which it uses to process rights enablement messages (REMs) and key derivation messages (KDMs). From a REM and KDM, the security module derives key data corresponding to content, uses public key and/or symmetric cryptography to re-encrypt the derived key data for another device, and provides the re-encrypted key data to the decoding device. The decoding device then uses cryptographic values derived from the re-encrypted key data to decrypt the content.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a continuation of U.S. application Ser. No.09/948,473, filed Sep. 6, 2001 and to issue as U.S. Pat. No. 6,640,305,which is a continuation of U.S. application Ser. No. 09/389,268, filedSep. 2, 1999, now U.S. Pat. No. 6,289,455, both of which are herebyincorporated by reference in their entirety.

FIELD

[0002] This patent relates to systems for distributing digital content,and more specifically to methods and apparatuses for improving thesecurity of systems for distributing digital content.

BACKGROUND

[0003] Introduction

[0004] Systems that protect valuable content require effective security.For content distributed in physical form, such as film being transportedto movie theaters, physical security measures can be sufficient.Unfortunately, traditional physical security techniques are slow,expensive, cumbersome, and cannot be used with non-physical contentdistribution models. As a result, content providers rely oncryptographic hardware to ensure that only authorized users can accesstheir data.

[0005] To prevent misuse of decryption keys, cryptographic hardware usedto manage content decryption keys must be effectively tamper-resistant.Building effective tamper resistant hardware has proven extremelydifficult, especially for systems that are the subject of determinedattacks, because they are large or protect high-value content. As aresult, many systems (including most satellite television systems) usereplaceable security devices, such as smartcards, so that security canbe re-established after an attack without replacing the entire playbacksystem. Nevertheless, smartcards used for prepaid telephone, pay-TV, andtransit applications are broken regularly. For example, prepaidtelephone cards used in Germany were attacked in 1998 with estimatedlosses of US$38 million (“Pirates Cash in on Weak Chips,” Wired News,May 22, 1998). Similarly, access cards and systems for cable and prepaidsatellite television services are regularly “hacked,” necessitatingrepeated costly card replacements.

[0006] Smartcards must effectively resist a variety of attacks againstcryptographic algorithms, protocols, software, and chip hardware.Unfortunately, designing a smartcard that implements sophisticatedprotocols yet contains no security flaws has proven to be a verydifficult task, since unexpected problems or errors in any portion ofthe design can render the entire card insecure. Cost considerations alsofavor attackers, since smartcards typically cost between $1 and $15, yetmay be trusted to protect services or information worth thousands ofdollars.

[0007] A smartcard system will only be attacked seriously if it is inthe attacker's interest to break it. With smartcard designs of thebackground art, once attackers develop a means to compromise one card,the incremental cost to break a large number of cards is usually verysmall. As a result, smartcard security efforts typically focus onpreventing the initial attack by making the card more difficult tobreak. For example, vendors try to increase the cost ofreverse-engineering the device or imaging the card's ROM. Suchtechniques are helpful because they increase the cost required to breakthe system the first time, but for very large systems they areineffective because attackers will devote enough effort to attacks thatthey will eventually succeed.

[0008] Prepayment and Post-Payment

[0009] In many systems of the background art, digital content isdistributed in encrypted form. Access to the keys or algorithms requiredto decrypt the content is regulated by a rights management system thatenforces the content owner's access policies. These access policies varygreatly in complexity. For example, the simplest schemes simply involveproviding a decryption key upon payment, while the approaches describedin U.S. Pat. No. 5,915,019 to Ginter et al. provide for rathersophisticated and flexible distribution mechanisms.

[0010] The two most common payment methods present in such schemes areprepayment and post-payment. Because these approaches have differentsecurity requirements, their architectures and typical requirements willbe described separately.

[0011] In prepayment schemes, the user obtains prior authorization fromthe content provider. In typical prepayment systems, the user provides apayment (or a commitment to pay) then receives a content decryption keythat allows access to the purchased content.

[0012] Prepayment systems must effectively be able to resist a varietyof attacks. One class of attacks involves directly breaking theencryption (or any other protection mechanisms used to preventunauthorized use of the content). Another attack involves capturing andredistributing the digital content after it has been decrypted. Otherattacks involve unauthorized redistribution of the content decryptionkeys. Still other attacks involve capturing the content in analog form(e.g., as it is presented to the user).

[0013] Some of these attacks can be prevented effectively and others donot present a serious financial threat to content distributors. Strongencryption algorithms (such as triple DES) can reliably thwart attackerswho do not have the correct decryption keys. Attacks against thedecrypted content are not very serious if the content's value decreasesrapidly with time or if the re-recording process significantly degradesthe quality of the content. Watermarking techniques can also prevent,detect or trace some content recording attacks. Attacks that involvecopying decryption keys are serious and have proven challenging toprevent. Because it is usually impossible or too expensive to transmit adifferent ciphertext to each potential user, attackers can purchase adecryption key once, then redistribute it to unauthorized parties.

[0014] Systems known in the background art distribute content decryptionkeys in encrypted form to a tamper-resistant cryptographic unitconnected to (or part of) the user's playback device. Because decryptionkeys with long-term value are never exposed in unencrypted form, manyattacks can be prevented—if the tamper-resistant module is unbreakable.

[0015] Because smartcards and other tamper-resistant cryptographichardware commonly used to implement the cryptographic unit often havelimited performance and bandwidth, the cryptographic unit is often usedto generate short-lived subkeys from the main content decryption key.These subkeys are then transmitted to a less secure portion of thesystem, such as the main playback device, and used to decrypt thecontent itself.

[0016] The security of the system thus depends on the security of thecryptographic unit. If the cryptographic unit is compromised, attackerscan determine the decryption keys and algorithms and use these to accesscontent without authorization (e.g. by emulating an authorizedcryptographic unit and/or the entire playback device).

[0017] In post-payment schemes, the user can decide to access somecontent without notifying the content provider or obtaining permissionin advance. Instead, the content provider later audits the user's usageand determines the appropriate fees to charge. In some systems of thebackground art, post-payment is referred to as pay-per-view.

[0018] In addition to being susceptible to the attacks described aboveagainst prepayment systems, post-payment schemes are vulnerable to avariety of additional attacks. For example, the user's purchase auditrecords must be stored until the content provider retrieves them.Modification or destruction of these records can make it impossible forthe content provider to determine the correct amount to charge. As aresult, secure storage is required in the cryptographic unit for theaudit data.

[0019] Although cryptographic techniques can secure the audit data fromtampering (provided that the cryptographic unit has not beencompromised), users generally do have the ability to prevent the auditprocess altogether. For example, in many consumer systems, two-waycommunication requires a telephone call, which users can prevent bysimply disconnecting the telephone line. Users can often even destroythe cryptographic unit to conceal their purchases. As a result, measuresare generally required to make users allow audits. For example, it ispossible to penalize users by terminating service or preventing accessto additional post-payment (pay-per-use) content if successful auditsare not performed in a timely manner. Back-end systems can also chargeusers with penalties or other fees for audit noncompliance.

[0020] Post-payment systems involve more risk because purchases occurwithout live interaction with the content provider. As a result, eachcryptographic unit is typically preprogrammed with the cryptographickeys for viewing all content the user might possibly purchase. As aresult, compromise of a single cryptographic module can potentiallycompromise all post-payment content in a system.

[0021] Many systems combine prepayment and post-payment approaches.Prepayment is generally used to regulate access to content sold on asubscription basis. For example, access to electronic news services,music channels, subscription television channels, etc. are commonly soldon a prepayment basis. Premium content is often provided on apost-payment (pay-per-use) basis, where users can use content at anytime but their cryptographic modules periodically provide the contentprovider with a list of the premium content that has been used.Post-payment of this type is used in the “Divx” video playback system aswell as most cable and satellite television “pay-per-view” schemes.Prepayment protocols can be used for extremely high value pay-per-viewcontent if penalties are insufficient to ensure successful auditing orif the risks are great enough to offset the cost and effort to initiatetwo-way communication with the content provider before access isauthorized.

[0022] The Cryptographic Rights Unit (CRU)

[0023] A variety of designs and architectures have been proposed andused for cryptographic units that manage and protect the secret keys andalgorithms used in content distribution systems. If legitimate users canbe trusted to protect their keys, software-only approaches can beacceptable and have the advantage of avoiding the cost and expense ofbuilding and distributing specialized hardware. In many cases, however,tamper-resistant modules are required.

[0024] No architecture can provide perfect security. For example, anexact replica of an authorized satellite television receiver (includingthe receiver's cryptographic rights unit) will be able to view the samesignals as the original. As a result, the security depends on preventingattackers from building working copies or emulators of authorizedplayback devices.

[0025] Commercially-deployed approaches usually use tamper-resistanthardware modules to enforce the content provider's access policies. FIG.1 shows a smartcard of the background art for regulating access toencrypted content. The exemplary system includes three types of memory110: ROM 115, EEPROM 125, and RAM 120. Each type of memory hasadvantages and disadvantages. ROM is fast and inexpensive, but cannot bemodified and can often be read using advanced imaging techniques. RAM isfast and can be updated quickly, but loses its contents when power islost. EEPROM retains its contents even when power is disconnected, butis relatively expensive to manufacture and is quite slow to modify.

[0026] The ROM and/or EEPROM generally include software, which isexecuted by microprocessor 140. The software includes instructions thatimplement and/or manage protocols and cryptographic keys involved indecrypting content. Because cost, memory, and I/O bandwidth limits makeit difficult to decrypt a large amount of data in the tamper-resistantmodule, the tamper-resistant module can supply content decryption keysfor individual blocks or streams of content to the playback system,which performs the bulk data decryption. A cryptographic processor 150can optionally assist with the cryptographic computations by reducingthe amount of time or program code required for the computation or byimplementing obfuscated algorithms that are difficult to reverseengineer.

[0027] To support both prepayment and post-payment, at least four basicoperations are supported over I/O interface 145: adding new prepaidrights keys or privileges, recording purchases (for post-payment),deriving content decryption keys (for either prepayment orpost-payment), and post-payment auditing.

[0028] The device of FIG. 1 can potentially be attacked in a variety ofways. Attackers typically begin by extracting the software code from onedevice using any of a wide variety of techniques, such as physicallyimaging a chip or modifying a target chip using ion beam lithography.Although many techniques for performing the ROM and/or EEPROM extractionare relatively expensive, the operation only has to be performed once,since all units in the system normally have the same or similarsoftware. Some techniques, such as tamper-resistant chip coatings,memory encryption, etc. can complicate memory extraction attacks, butsuch techniques are expensive to implement and only increase the costfor performing the software extraction.

[0029] Once the software is known, attackers can reverse engineer thecode, yielding all cryptographic algorithms and keys contained in theextracted regions. Again, some techniques, such as the use of obfuscatedor nonstandard software, can complicate this process somewhat.

[0030] If cryptographic processor 150 is not present, the attacker canthen produce an emulator of the target device. Once an emulator has beendeveloped, it is often difficult for the provider of the system tore-establish security without replacing all CRUs. Even if legitimatedevices are configured to allow updates to the portions of theirsoftware or keys in EEPROM, the emulator will simply accept the sameupdates and continue operating unless the content provider manages toidentify the compromised keys and stop providing service to thecorresponding accounts.

[0031] If the emulator is imperfect and legitimate devices areconfigured to allow software updates, it may be possible to modifylegitimate devices in a way that the emulator will not processcorrectly. Unfortunately, all the attacker has to do is correct theemulator. For example, pirates have produced CRU emulators that operatea personal computer and updated their emulator software to fix anyerrors in the emulator's operation.

[0032] Code update capabilities are a double-edged sword—although theycan thwart some attacks, attackers may be able to subvert them to injectmalicious code into legitimate devices. Although code updates can beprotected with digital signatures and/or MACs (Message AuthenticationCodes), attacks against the hardware, software, and/or cryptography posea significant risk. It may also be possible for attackers to insert codein other ways, for example by exploiting pointer errors to redirectmemory updates to code regions.

[0033] For example, if the attacker is able to trick microprocessor 140into executing malicious (i.e., attacker-written) code, then theattacker can use the first code to load more malicious code into EEPROM125 or RAM 120. This malicious code can then further modify the device,for example by adding unauthorized functions that bypassnon-cryptographic protections, delete post-payment audit records,add/modify/output cryptographic keys such as rights keys, etc. Althoughsome techniques (such as hashing EEPROM contents as part of keyderivation processes) have been attempted to detect some such attacks,these techniques tend not to be very effective and have been evaded byclever attackers. Although it would be possible to make microprocessor140 execute only code from ROM 115, the system designers would then beunable to patch problems or transmit code updates to address bugs.

[0034] It is extremely difficult or impossible to reliably prevent allmajor attacks using architectures of the background art. Once attackersreverse engineer the software executed by microprocessor 140, they canidentify and exploit software flaws or other implementation weaknesses.If these weaknesses in turn allow unauthorized modification of thedevice's software, the content provider's own cryptographic rights units(CRUs) and/or playback hardware can even be used to attack the system.The book European Scrambling Systems 5 by John McCormac (BaylinPublications, 1996) contains more information about how some existingsystems have been designed and attacked and why architectures of thebackground art have proven ineffective.

[0035] Using architectures of the background art, any weakness in thecryptographic unit thus tends to cause a serious compromise of theentire device. Building a device that resists all known invasive andnon-invasive hardware attacks, software attacks, protocol attacks,cryptographic attacks, fault induction attacks, etc. is extremelydifficult—and new attacks may be discovered after a device is deployed.As a result, many content providers suffer from high piracy rates andthe expense of replacing cryptographic units when they are broken.

SUMMARY

[0036] The technologies disclosed herein can improve the security ofsystems used to distribute and protect digital content. In oneembodiment, a tamper-resistant device for regulating access to encodeddigital content includes an external interface, a microprocessor forcontrolling the external interface, a memory, a cryptographic unitconnected between the microprocessor and memory configured to protectthe memory from the microprocessor by cryptographically transformingdata communicated between the microprocessor and the memory, and adevice key accessible by the cryptographic unit and inaccessible by themicroprocessor. The device is configured such that the cryptographicunit uses the contents of the memory to transform at least one datavalue received from the microprocessor, where the result of thetransformation is required to decode the digital content.

[0037] Although it is impossible to design a content distribution systemthat is immune to all possible piracy attacks, it is desirable tominimize the probability that attackers will profit from attacks. Asystem does not need to be immune to all attacks; attackers aregenerally rational and driven by a profit motive, so illogical attackswill not proliferate widely. For example, if the attacker's cost andrisk exceed the cost of purchasing the content legitimately, piracy isnot a serious threat.

[0038] Attackers have both advantages and disadvantages as compared tolegitimate service providers. Because their acts are often illegal, theyincur higher risks. Their distribution costs and customer acquisitioncosts tend to be higher, since they generally cannot use traditional(legitimate) channels. The quality and reliability of pirate servicesalso tends to be inferior. On the other hand, attackers have severalmajor advantages. Most important, they obtain their content for free(i.e., by pirating it). In many cases they also co-opt part or all of acontent provider's distribution channel (e.g., sales of encryptedoptical discs, satellite broadcasts, Internet services, etc.), playbackmechanisms (cable TV set-top boxes, DVD players, etc.), and otherinfrastructure. Finally, pirates' customers may be able to avoidcumbersome procedures imposed by the legitimate content provider forsecurity, billing, etc.

[0039] Although attacker business models vary, the technologiesdisclosed herein are based on the premise that content providers caneffectively eliminate piracy by making it unprofitable. It is thusdesirable to increase the costs and risks incurred by attackers whosteal content.

[0040] Content providers will only invest in anti-piracy measures thatmake business sense. When estimating the cost of content piracy tocontent providers, several factors should be considered. Direct revenuelosses occur when potential subscribers instead buy pirated content. Incases where content providers subsidize the costs of media,distribution, playback hardware, technical support, etc., illegitimateusers can also increase expenses. If piracy is widespread, contentproviders may be unable to obtain premium content or will have to paymore to content owners to compensate them for lost royalties. Costs forenforcement and prosecution can also be significant. Paying users mayeven feel discouraged if they see others getting for free what they arepaying for, reducing the perceived value of a service. It is thusdesirable to achieve improved security without unduly increasing costsor hassles for content providers or legitimate users.

[0041] Traditional content protection schemes generally seek to maximizethe cost of any unauthorized access, but do little to increase the costof decoding messages once the decryption scheme has been broken. Inaddition to preventing attacks, it is also desirable to seeks tominimize the proliferation of unauthorized decoding devices if an attackdoes occur, since the damage due to piracy increases with the number ofunauthorized users. For example, one might seek to increase or evenmaximize the cost of producing multiple unauthorized pirate devices evenafter one device has been compromised. This is attained in part byforcing attackers to repeat complex and expensive physically-invasiveattacks for each pirate device that is produced.

BRIEF DESCRIPTION OF THE DRAWINGS

[0042]FIG. 1 shows a smartcard of the background art for regulatingaccess to encrypted content.

[0043]FIG. 2 shows an exemplary system using ??? the CryptographicRights Unit (CRU).

[0044]FIG. 3 outlines an exemplary embodiment of a process for addingrights using prepayment.

[0045]FIG. 4 outlines an exemplary embodiment of the rights additionprocess using post-payment.

[0046]FIG. 5 shows an exemplary method for deriving CDKs using rightskeys stored in the CryptoFirewall's protected memory.

[0047]FIG. 6 shows exemplary processes for auditing and clearing auditdata.

[0048]FIG. 7 diagrams an exemplary multi-targeting technique and showshow it can be used to renew rights keys.

[0049]FIG. 8 illustrates one embodiment of a pseudoasymmetric functiongenerator (PAFG).

[0050]FIG. 9 diagrams the operation of an exemplary CryptoFirewall thatimplements prepaid rights and can be easily extended to supportpost-paid rights.

[0051]FIG. 10 shows an exemplary CryptoFirewall embodiment using a smallvolatile protected memory and using batch keys to minimize the bandwidthrequired for REMs.

[0052]FIG. 11 diagrams the content decryption key computation process ofFIG. 10.

DETAILED DESCRIPTION

[0053] The following description is provided in the context of aparticular application and its requirements. Various modifications tothe disclosed embodiments will be readily apparent to those skilled inthe art, and the general principles defined herein may be applied toother embodiments and applications without departing from the spirit andscope of the general techniques disclosed herein.

[0054] Exemplary Meanings

[0055] The following are provided as exemplary meanings of some commonlyused terms in this patent. However, unless expressly indicated, theseexemplary meanings should not be understood to supersede other possiblemeanings (including their customary ordinary meanings) known to thoseskilled in the art. In addition, although capitalization has been usedas an aid to readability, such capitalization should not be construed aslimiting the meaning of such terms to the various exemplary disclosurescontained in this patent. Rather, the terms should be given their entirerange of possible meanings not inconsistent with the disclosure of thispatent.

[0056] Asymmetric Function: An easy-to-compute function for which acomplementary operation (such as its inverse) is computationally hardwithout a private key, but easy to compute with the private key. The RSAcryptosystem is thought to be asymmetric, since inverting the public keyoperation (i.e., performing the private key operation) is only easy withif the private key is known.

[0057] Content Decryption Key (CDK): A key required to decrypt someencrypted digital content.

[0058] Content Provider: An entity that manages the cryptographicportions of a content distribution system. The content provider is alsogenerally responsible for distributing or broadcasting the content,billing, customer service, etc. The content provider tasks can bedivided among many companies.

[0059] CryptoFirewall: A specialized circuit placed between theinterface control processor (ICP) and a protected memory which isdesigned to control access to (and use of) the protected memory even ifthe ICP is compromised. In addition, the CryptoFirewall uses theprotected memory to derive content decryption keys.

[0060] Cryptographic Rights Unit (CRU): A tamper-resistant hardwaredevice designed to perform cryptographic operations that allowauthorized users to gain access to digital content.

[0061] Device key: A cryptographic key or other security-relatedparameter that is preferably specific to a particular device, but mayalso be shared by a small number of similar devices.

[0062] Digital content: A digital representation of human-interpretablematerial, such as pictures, audio tracks, video segments, text (such asbooks, magazines, news feeds, stock quotes, etc.), etc. Digital contentis often encrypted and/or compressed and may include error correctingcodes and other auxiliary data.

[0063] Interface Control Processor (ICP): A microprocessor responsiblefor processing communications between the cryptographic rights unit anda playback device. The ICP is also generally responsible forcommunicating with the CryptoFirewall.

[0064] ISO 7816 Smartcard: A device complying with at least the physicaldimensions and contact configurations specified in ISO standard 7816-1and 7816-2. Smartcards are commonly used to implement CRUs, as theyprovide a reasonable degree of tamper resistance at relatively low cost.

[0065] Key Derivation Message (KDM): A message generated by a contentprovider to allow a CRU to derive a decryption key corresponding to somedigital content. KDMs are usually transmitted with the correspondingcontent.

[0066] Playback Device: A device that receives digital content via anuntrusted mechanism (such as radio, optical disc, digital audio tape,cable, satellite broadcast, Internet connection, etc.) and, using a CRU,decodes the content. The bulk data decryption operation can be performedby the CRU itself or by the playback device using a key generated by theCRU.

[0067] Pseudoasymmetric Function: A function (transformation) designedsuch that attackers cannot easily perform the inverse transformationeven with direct access to the forward transformation. For example, anattacker with access to a pseudoasymmetric encryption function does notnecessarily have the ability to decrypt meaningful messages. Unliketraditional asymmetric cryptographic functions, however, thenoninvertability of a pseudoasymmetric function relies on the difficultyof completely reverse engineering the “public” function instead of thedifficulty of performing a mathematically hard operation such asfactoring. A block cipher implementation with a physically-protected keyand/or algorithm that only supports encryption is an example of apseudoasymmetric function, since unrestricted access to the encryptionoperation alone does not allow decryption of messages.

[0068] Rights Enablement Message (REM): A message generated by a contentprovider that gives a CRU the ability to access new content. The REMitself is usually transmitted via the same untrusted mechanism as thecontent itself, although in some cases REMs may be exchanged throughother channels (such as separate telephone or Internet connections).

[0069] Rights Key: A value (such as a cryptographic key) that allows aCRU to generate or decode the decryption keys for some content. Rightskeys are generally required to decrypt KDMs and obtain contentdecryption keys.

[0070] Tamper-Resistant Device: A hardware device whose operation isrelatively difficult to monitor and/or modify. Examples oftamper-resistant devices include without limitation PCMCIA cards filledwith epoxy, circuits covered with tamper-resistant coatings, circuitswrapped in tamper-detecting wire, integrated circuits (which are tamperresistant due to their small feature size), and circuits in enclosuresthat detect opening.

[0071] System Architecture

[0072]FIG. 2 shows an exemplary system using an exemplary CryptographicRights Unit (CRU). Content Provider 200 obtains content and prepares itfor distribution, for example by compressing and encrypting contentdata, multiplexing multiple content streams, and adding control messagessuch as KDMs and REMs. (A more detailed explanation of the contentpreparation process is provided in the section below entitled “PreparingContent.”)

[0073] The encrypted content data is then distributed (process 205) bythe Content Provider in a manner such that it can be received byauthorized (e.g., paying) users as well as potential attackers. Avariety of distribution methods may be employed, including withoutlimitation distribution of physical media (such as optical discs), radioor satellite transmission, wired networks (such as telephone, ADSL,cable television, etc.), and distribution over computer networks (suchas publication on a web site, multicast, etc.)

[0074] Playback device 210 receives the distributed data for somecontent to be decoded. In the exemplary embodiment shown in FIG. 2, KeyDistribution Messages (KDMs) and Rights Enablement Messages (REMs) aredistributed with content 205. Playback device 210 thus separates thedesired content 215 and control messages 220 in the received data.

[0075] In the exemplary embodiment, control messages 220 include KeyDerivation Messages (KDMs) and Rights Enablement Messages (REMs). Thesemessages are transferred by playback device 210 to Cryptographic RightsUnit (CRU) 225. Playback device 210 can optionally perform processing orfiltering before sending messages to CRU 225.

[0076] CRU 225 includes an interface control processor (ICP) 235, whichis responsible for communication with playback device 210 via I/Ointerface 230. In addition, CRU 225 includes several types of memoryconnected to interface control processor 235 via bus 240. In particular,fixed data and code are stored in ROM 245, temporary data (and possiblycode) are stored in RAM 250, and additional code and/or data are storedin EEPROM 255 which can be modified by processor 235. Also attached tobus 240 is CryptoFirewall 260, a specialized cryptographic processingunit whose operation is explained in detail below. CryptoFirewall 260regulates and cryptographically modifies data written to or read fromprotected memory 265.

[0077] To decode some content, playback device 210 transmits tointerface 230 a KDM corresponding to some content 215 to be decoded.Interface control processor 235 receives the KDM and, as describedbelow, uses CryptoFirewall 260 to derive one or more content decryptionkeys 267, which are transferred to bulk decoder 270 via playback device210. With the correct keys 267, bulk decoder 270 can correctly decryptcontent 215. The decrypted content 275 is then sent to an output device280, which presents the content to user 290 by converting it into ahuman-readable form (process 285). For example, if the system isconfigured to play audio content, decrypted content 275 could be ananalog or digital representation of a sound, and output device 280 couldbe an amplifier and speakers. Similarly, if the system is configured toplay movies on a television set, bulk decoder 270 could performdecryption and MPEG decompression, outputting decrypted content 275 asan NTSC-compatible video signal so that output device 280 can be anordinary television set.

[0078] A communication channel from CRU 225 to content provider 200 isalso provided for auditing post-payment purchases. This channel can alsobe used for transmitting REMs, other usage data, code updates, etc.Communication from the CRU to the content provider can be direct 296 or(more commonly) indirect 295, e.g. passing through playback device 210which can (for example) establish a connection with content provider 200as needed. Any communication method (including without limitation modem,radio, satellite, cable, etc.) can be employed.

[0079] CryptoFirewall Operation

[0080] The CryptoFirewall cryptographically regulates access to aprotected memory. Unlike conventional memory encryption devices (such asthe encrypted memory device of U.S. Pat. No. 5,442,704 to Holtey), theCryptoFirewall does not act transparently or allow arbitrary read orwrite operations to be performed by the microprocessor. In particular,the CryptoFirewall does not need to provide the microprocessor with theability to store data values in the protected memory and read the samevalues out later. Conventional secure memory schemes are typically usedto allow a trusted computational device to access memory that is lesssecure. In contrast, the CryptoFirewall is designed with the oppositeassumption, that the interface control processor is untrusted butattackers do not have direct read/write access to the memory behind theCryptoFirewall. In other words, the CryptoFirewall can allow thecryptographic rights unit to remain secure even if the CRU's mainmicroprocessor is compromised, provided that attackers do not completelybreach the firewall and gain unrestricted access to the protectedmemory.

[0081] The CryptoFirewall implements a set of basic operations involvedin adding and using content access rights. In the exemplary embodimentdescribed with respect to FIGS. 3, 4, 5, 6, and 7, these operationsinclude adding new rights by prepayment, adding new rights forpost-payment, accessing content, auditing/clearing post-paid purchaseaudit records, and renewing rights. The interface control processor isresponsible for supplying data to the CryptoFirewall for each of thesecommands and assisting with non-security critical tasks.

[0082] The exemplary CryptoFirewall uses several keys, which are storedin protected memory 265 and loaded during personalization (describedbelow). In one embodiment, the protected memory is an EEPROM containinga device key (CHIP_KEY), at least one group key shared by (for example)32 cards (BATCH_KEY), a post-payment authorization key (POSTAUTH_KEY),and several rights keys. Portions of the protected memory containingdevice keys and group keys can be written during personalization, thenlocked (write protected) to prevent future modification. Alternatively,these values can be stored in ROM, within or accessible by theCryptoFirewall.

[0083] Adding new rights by prepayment: FIG. 3 outlines an exemplaryembodiment of a process for adding rights using prepayment. When a userpurchases (or otherwise obtains) permission to use some content, theplayback device receives an appropriate rights enablement message (REM)at step 300. The REM is optionally processed and/or validated by theinterface control processor, which locates an encrypted rights key inthe REM. The interface control processor also selects a destinationaddress in the protected memory. At step 310, the encrypted rights keyand address are transferred to the CryptoFirewall, which performs thesubsequent processing steps (labeled 320). At step 330, theCryptoFirewall validates that the address specified is valid for storingprepaid rights. At step 340, the CryptoFirewall reads CHIP_KEY (achip-specific key or device key) from the protected memory. At step 360,the encrypted rights key is transformed using pseudoasymmetric functionF₁ keyed using CHIP_KEY. At step 370, the CryptoFirewall stores theresult of transformation F₁ (i.e., the rights key) in the protectedmemory at the validated address. Note that the process of FIG. 3 canalso be used to delete or replace rights keys (e.g., by over-writingthem), although key deletion is not essential for broadcast systems(such as cable or satellite television) since content providers cansimply stop distributing content protected using expired keys.

[0084] Adding new rights by post-payment: Rights added by post-paymentare different from prepaid rights because no explicit communication orprior authorization is available from the content provider. FIG. 4outlines an exemplary embodiment of the rights addition process usingpost-payment. When a user wishes to gain access to content on apost-paid basis, the interface control processor obtains at step 400 arights enablement message corresponding to the content access right tobe added. The REM includes an identifier of the content. (The contentidentifier can be a simple identifier, a randomly produced orcryptographically generated value, a counter, a combination ofparameters, etc. and may be generated by the content provider, ICP,playback device, CryptoFirewall, etc.) At step 410, the contentidentifier and a destination address are passed to the CryptoFirewall,which performs the subsequent processing steps (labeled 420). At step430, the CryptoFirewall verifies that the address is valid for storingpost-paid rights. At step 440, the CryptoFirewall verifies that storingaudit data at the specified address will not replace an existingpost-payment purchase record in the protected memory. At step 460, theCryptoFirewall uses a pseudoasymmetric function F₂ to transform thecontent identifier. (The function F₂ can, for example, be keyed with apost-payment authorization key POSTAUTH_KEY or a global key or, ifseparate post-payment KDMs are distributed for batches of CRUs, a batchkey.) At step 470, the CryptoFirewall stores the result (the rights key)in the protected memory.

[0085] Accessing content: Before a user can access some content, theplayback device must obtain the correct content decryption key (CDK) sothat the content can be decrypted. FIG. 5 shows an exemplary method forderiving CDKs using rights keys stored in the CryptoFirewall's protectedmemory. At step 500, the interface control processor (ICP) receives akey derivation message (KDM) from the playback device. At step 510, theICP uses the KDM to obtain a CDK generator value. (The CDK generator istypically an encrypted form of the CDK and is part of the KDM.) The ICPthen sends the CDK generator and an address in the protected memorycorresponding to the appropriate rights key to the CryptoFirewall, whichperforms steps 520 through 560. (To assist with selecting the correctaddress, the ICP can use its nonvolatile memory to keep track of therights keys and their locations. The KDM also can identify which rightskey is appropriate for processing each CDK generator.) At step 520, theCryptoFirewall verifies that the address is valid, then, at step 530,retrieves the corresponding value (the rights key) from the protectedmemory. At step 550, the CryptoFirewall uses pseudoasymmetric functionF₃, keyed with the rights key that was read from the protected memory atstep 530, to transform the CDK generator. (In an alternate embodiment,F₃ can be keyed with the CDK generator and used to transform the rightskey itself. Also, F₃ does not necessarily need to be a pseudoasymmetricor invertable function. For example, F3 can be a hash) At step 560, theCryptoFirewall returns the transformation result to the ICP. At step570, the ICP optionally performs any final processing required toproduce the final CDK from the F₃ result. At step 580, the ICP transmitsthe CDK to the playback device, which, at step 590, uses the CDK todecrypt the content.

[0086] Auditing and Clearing Post-Payment Rights: A secure audit processis required to allow the content provider to charge users forpost-payment purchases. To perform an audit, the content provider mustbe able to receive data from the cryptographic rights unit, for examplethrough a modem or computer network connection with the playback device.The audit process can be controlled by the interface control processor,which in turn communicates with the CryptoFirewall. FIG. 6 showsexemplary processes for auditing and clearing audit data. At step 600,the content provider transmits an audit initiation request message tothe interface control processor. (The process used to initiate audits isimplementation-specific. For example, the CryptoFirewall or ICP canalternatively notify the playback device that an audit is needed so thatthe playback device can establish a connection with the contentprovider. In another embodiment the content provider can broadcast amessage to the CRU requesting that it perform an audit. In anotherembodiment, the content provider can directly establish a connectionwith the CRU or playback device.) The exemplary audit initiation messageincludes an unpredictable and/or unique challenge value generated by thecontent provider. At step 610, the CryptoFirewall receives an addressvalue and the challenge value corresponding to a first address to audit.At step 620, the CryptoFirewall verifies that the address is valid forauditing. At step 630, the CryptoFirewall retrieves the contents of theprotected memory corresponding to the specified address and a device key(e.g., CHIP_KEY). At step 640, the CryptoFirewall combines the memorycontents and the address (for example by concatenating them or replacingpart of the memory contents with the address) and transforms the resultusing pseudoasymmetric function F₄ keyed with the CHIP_KEY XORed withthe challenge value. The ICP then receives the F₄ result and sends it tothe content provider via the playback device. At step 650, the contentprovider uses F₄ ⁻¹ (the inverse of F₄) keyed with the CRU's CHIP_KEYXORed with the challenge value to determine the actual contents of thememory at the specified address. Because F₄ is pseudoasymmetric andkeyed using the CHIP_KEY, the content provider (and only the contentprovider) should be able to perform F₄ ⁻¹. Unless an attack orcomputational error has occurred, the decryption result shouldcorrespond to either an unused (empty) post-paid rights slot or a rightskey for content sold on a post-payment basis. At step 660, the contentprovider decides whether to clear the slot that was audited.(Post-payment purchase records that are no longer needed by the CRUshould be cleared to make room for new purchases.) If no clearing is tobe performed, processing continues at step 690. Otherwise, at step 670,the content provider applies F₄ ⁻¹ again (keyed using CHIP_KEY) to theresult of the first F₄ ⁻¹ transformation. The result is transferred tothe CryptoFirewall via the playback device and the ICP. At step 675, theplayback device applies F₄ (keyed using CHIP_KEY) to the value received.At step 680, the playback device compares the result with the value readfrom the protected memory at step 630. If the values match, theCryptoFirewall performs step 685 and clears the protected memory slot.At step 690, the audit process repeats back to step 610 if moreaddresses in the protected memory need to be audited. Otherwise, theaudit process concludes. After a successful audit, the content providerperforms post-audit actions such as charging the customer for purchasesand refreshing pre-paid keys in the CRU. If the audit fails or indicatesinappropriate (or unknown) values in the protected memory, actions mightinclude terminating service to the playback device (or CRU), requiringthe user to return the CRU for replacement, billing the user fornoncompliance, and/or sending messages to cause the CRU to disableitself. The embodiment shown in FIG. 6 is exemplary; alternativeembodiments can, for example, perform auditing before audit recordclearing begins, use risk management techniques in the CryptoFirewall torequire audits and determine when they should occur, corrupt auditrecords if audit clearing authorizations are invalid, accumulate a hashof the audit data in the protected memory so that insecure memory can beused to store audit records, modify protected memory fields during theauditing process as well as during the record clearing process, etc.

[0087] Multiple Targeting: In some environments, it may not be feasibleto broadcast different REMs to all users. For example, if REMs aredistributed with content stored on optical discs, broadcast by radio, orsent via satellite, the data required for REMs is typically distributedto all users. As a result, the bandwidth and cost for distributing REMsincrease as the system grows larger and can eventually becomeprohibitive. It is possible to reduce the amount of REM data by allowingmultiple authorized CRUs to use each REM. FIG. 7 diagrams one exemplarymulti-targeting technique and shows how it can be used to renew rightskeys. At step 700, the playback device receives a REM, which includes arights key fixup value encrypted with a key shared by a batch of CRUs aswell as several smaller (e.g., 3-bit) chip-specific fixup values. Forexample, if a BATCH_KEY is shared by 256 CRUs, a separate 3-bit chipfixup value is included for each of these CRUs authorized to use theREM. At step 710, the CryptoFirewall receives the rights key fixupvalue, the address to update, and the chip-specific fixup valuedesignated for this CRU. At step 720, the CryptoFirewall validates theaddress received from the interface control processor to ensure that itcorresponds to an updateable key in the protected memory. At step 730,the CryptoFirewall reads the CHIP_KEY from the protected memory. At step740, the CryptoFirewall uses pseudoasymmetric function F₅ keyed withCHIP_KEY to transform the rights key fixup value. At step 750, the F₅result is truncated or compressed to a 3-bit quantity and the truncatedvalue is combined with the 3-bit chip-specific fixup value received atstep 710. (The combining can be done, for example, by XORing the two3-bit values together, adding them modulo 8, etc.) Note that the resultof step 750 will match a value chosen by the content provider if thechip-specific fixup value is correct, but otherwise produce a differentvalue. An attacker who attempts to guess the chip-specific fixup valuewill cause the result of step 750 to be incorrect ⅞ (87.5 percent) ofthe time. At step 760, the 3-bit result of step 750 is combined with therights key fixup value received at step 710, for example by XORing theresult of step 750 onto the first 3 bits of the rights key fixup value.At step 770, the CryptoFirewall reads from the protected memory the dataat the address received at step 710 and XORs with the BATCH_KEY. (If theBATCH_KEY is stored in the protected memory, it is also read at thisstep.) At step 780, the CryptoFirewall transforms the result of step 760using pseudoasymmetric function F₅, keyed with the result of step 770.Finally, at step 790, the result is written to the protected memory atthe specified address. Because the attempts to perform an unauthorizedkey update will corrupt the key most of the time (i.e., with probability2^(−k) for a k-bit chip-specific fixup value), attackers will not beable to perform unauthorized key updates with a high enough success rateto produce a commercially-viable attack. Note: another embodiment ofgroup targeting is described below with respect to FIGS. 10 and 11. Manyvariants of the embodiment shown in FIG. 7 are also possible; see (forexample) the section below entitled “Variations.”

[0088] Personalization

[0089] During personalization, keys including the CHIP_KEY and BATCH_KEYare added. If manufacturing processes allow, these keys can be stored inthe CryptoFirewall during manufacture, for example by blowing on-chipfuses. They can also be stored in the protected memory, but care shouldbe taken, however, to prevent attackers from being able to store keyvalues from one CRU in another. Methods usable to prevent such attacksinclude preventing write access to the key regions after personalization(e.g., by blowing a write-protect fuse), cryptographically regulatingaccess to these regions, and disabling either bit clearing or bitsetting operations to prevent attackers from transforming one key intoanother. (Valid keys can be chosen with equal numbers of set and clearbits to ensure that key changes will require both setting and clearingbits.) It is even possible to allow modification of the keys, providedthat changes performed using non-invasive attacks have a highprobability of corrupting the key without producing useful results.

[0090] Pseudoasymmetric Function Generation

[0091] Pseudoasymmetric functions are included in preferredarchitectures as they can help limit the consequences if a single deviceis compromised. Cryptographic protocols alone (without hardware tamperresistance) cannot prevent many attacks against broadcast contentdistribution systems, since an unauthorized replica of an authorizedplayback system will be able to decode signals. As a result, thehardware implementation should be difficult to reverse engineer orclone.

[0092] In one embodiment, a pseudoasymmetric algorithm is produced usinga software-implemented generator. The generator constructs a randomizedalgorithm using data from a random number source, such as a true randomnumber generator, a pseudorandom number generator (such as a streamcipher), a pre-computed randomized input file, etc. The generator usesthe random data to automatically design a hardware circuit that performsa cryptographic transformation. The purpose of the random source is toensure that the circuit construction and the function it performs areunknown to attackers.

[0093]FIG. 8 illustrates one embodiment of a pseudoasymmetric functiongenerator (PAFG). The input message is stored in a 128-bit shiftregister 800. The contents 810 of shift register bits 1 though 127 arelabeled U₁ through U₁₂₇. In addition, the 128-bits of a permutationselector (key) K are also available as K₀ through K₁₂₇ (labeled 802) anda clock cycle counter C is available as C₀ through C₁₅ (labeled 804).The computation circuit includes a series of sixty-four NAND gates 820having inputs V₀ through V₁₂₇ (labeled 815). For each NAND gate, thePAFG uses its random source to randomly select one input bit from U₁through U₁₂₇ and to randomly select the other input bit from among C₀ .. . C₁₅, K₀ . . . K₁₂₇, and U₁ . . . U₁₂₇. (To ensure that thetransformation in this exemplary embodiment is a permutation, theleftmost shift register bit, labeled 805, is not used here.)

[0094] The outputs of NAND gates 820 are labeled W₀ through W₆₃. Each ofthese is connected to one or more of X₀ through X₁₂₇ (labeled 835),where the specific choice of connections is made by the PAFG. Theremaining inputs to XOR gates 840 are connected to randomly-selectedbits from C₀ . . . C₁₅, K₀ . . . K₁₂₇, and/or U₁ . . . U₁₂₇. The XORgate outputs 850 (labeled Y₀ through Y₆₃) are connected by the PAFG toinputs randomly selected from Z₀ through Z₁₂₇ (labeled 855). Theremaining inputs to the final set of NAND gates 860 are selected fromamong C₀ . . . C₁₅, K₀ . . . K₁₂₇, U₁ . . . U₁₂₇, W₀ . . . W₆₃, and Y₀ .. . Y₆₃. Finally, the outputs of NAND gates 860 and the original 128-bitshift register's left-hand bit 805 are XORed together by XOR gates 870,producing a single-bit result 880. The 128-bit shift register 800 isthen shifted left one position (i.e., storing the contents of bit 1 intobit 0, bit 2 into bit 1, but 127 into bit 126, etc.) and the singleresult bit 880 is placed in bit position 127. To transform an inputblock, the operation shown in FIG. 8 is performed repeatedly with acorresponding increment or update to clock counter 804 after eachoperation. The key 802 can also be updated, for example by transformingit with a maximal-length shift register. The number of iterationsperformed is implementation-specific and may be variable, depending onfactors such as performance requirements and the quality of the mixingfunction.

[0095] Of course, the implementation illustrated in FIG. 8 issubstantially simplified, since a real hardware implementation could becomprised of many thousands of gates. In addition, the exemplaryembodiment uses only two types of gates (XOR and NAND), but other logicoperations may be employed in addition or instead. Additional inputs mayalso be incorporated into the computation or some inputs may be omitted(such as the counter C).

[0096]FIG. 8 uses a 128 bit to 1 bit basic transformation function, butother embodiments may also use other constructions for thetransformation. For example, the constructed function can have a Feistelstructure (which may be balanced or unbalanced). Constructions withoutthe regularity of a Feistel or shift register may also be used (and maybe advantageous since attacks such as microprobing the circuit forcomputation intermediates can made more difficult if there are a largenumber of interrelated internal intermediates). Even though it isusually advantageous that the pseudoasymmetric function be apermutation, some embodiments may produce functions that are not strictpermutations. Although the embodiment shown in FIG. 8 uses two inputparameters (a data block and a key block), alternate embodiments cancombine these, eliminate the key, or include additional parametervalues.

[0097] In some CryptoFirewall embodiments it is advantageous to usemultiple pseudoasymmetric functions to ensure that outputs from oneoperation cannot be used to attack other operations. To reduce the sizeof an implementation, it is possible to share many or all logiccomponents between these functions. A single transformation circuit canprovide multiple operations if a transformation selector is used. Forexample, a 3-bit function identifier placed in the most significant 8bits of the counter in C₀ . . . C₁₅ shown in FIG. 8 could provide foreight separate transformation operations.

[0098] The output of the PAFG can have any form, but is typically acircuit representation that can be included directly in anapplication-specific integrated circuit (ASIC). For example, standardlanguages (such as Verilog and VHDL) for designing integrated circuitsmay be used as the output format. Additional automated or manualmodification of the output (such as adding basic structures around thefunction, optimizing the operation, etc.) can be performed if required.

[0099] In a preferred embodiment, the PAFG also outputs a circuitdefinition for the inverse function in addition to the “forward”function. A hardware implementation of the forward function isdistributed to untrusted parties, for example in the CryptoFirewall,while the inverse is typically managed securely by the contentprovider(s) and used to prepare content, REMs, KDMs, etc. fordistribution. Because the devices that contain the inverse function areoperated by the content provider, they can be stored inphysically-secure locations. As a result, tamper-resistance is notrequired, so the inverse may (for example) be implemented in software orin programmable integrated circuits (such as FPGAs).

[0100] It is possible for the PAFG to be configurable to produce outputtailored to the implementation. For example, output can be tailored toaccommodate different circuit description languages, circuit sizes,layouts, logic gate (or logic cell) types, and wiring limitations. Forexample, in one embodiment, the PAFG is configured to produce a circuitof variable size so that a system designer can select an output circuitwhose size corresponds to the amount of space available on a chip's die.

[0101] One major advantage of the PAFG architecture is that it canproduce circuits that are difficult to reverse engineer while stillallowing open cryptographic evaluation. The PAFG itself does not need tocontain any secrets because it constructs the output circuit usinginterconnects and other design parameters generated using a randomsource. As a result, the PAFG design and implementation can beanalyzed—or even published for open review—to assess whether there isany significant chance that the PAFG will generate a cryptographicallyinsecure function. The PAFG architecture thus allows for unrestricteduse of outside review and does not require burdensome securityprecautions on the reviewers typically required when using obfuscatedalgorithms. The PAFG thus provides resistance to reverse engineeringwithout relying on security by obscurity. (Of course, PAFGimplementations that do not use good random sources can be constructedas well, but are not preferred.)

[0102] An Exemplary Simplified Architecture

[0103] The complexity of the CryptoFirewall described with regard toFIGS. 2 through 7 can be reduced significantly. This section outlinesone such simplified architecture that maintains the general memoryprotection and security features. In the first embodiment presented, theCryptoFirewall supports only prepaid rights, leaving other securityfeatures (such as post-payment purchase auditing) to be enforced by the(less secure) ICP. A disadvantage is that attackers who compromise theICP could potentially erase post-payment audit records, but an advantageis that the CryptoFirewall implementation is significantly simplified.

[0104]FIG. 9 diagrams the operation of an exemplary CryptoFirewall thatimplements prepaid rights but can be easily extended to supportpost-paid rights. The nonvolatile protected memory behind theCryptoFirewall contains a device key (CHIP_KEY) as well as memorylocations for storing prepaid rights keys. At step 900, theCryptoFirewall receives a key address from the ICP and makes sure thatthe address corresponds to a valid key offset in the protected memory.(For example, if keys are 8 bytes long, zeroing the three leastsignificant address bits ensures that the base address is notmis-aligned.) At step 910, the CryptoFirewall loads from the protectedmemory the data stored at the specified address and places the result ina key register. At step 920, the CryptoFirewall receives a data blockfrom the ICP. At step 930, the CryptoFirewall uses the key read at step910 with a pseudoasymmetric function to transform the data blockobtained at step 920. At step 940, the CryptoFirewall tests whether ifthe address read at step 900 corresponds to the location of the CHIP_KEYin the protected memory. If not, at step 950, the CryptoFirewall outputsthe pseudoasymmetric transformation result to the ICP and concludes.(Results produced using keys other than CHIP_KEY—i.e., rights keys—areused to derive content decryption keys, so the results are not stored.Transformations protected with the CHIP_KEY are used to add new rightskeys to the protected memory.) Otherwise, at step 960, theCryptoFirewall reads a second address from the ICP. At step 970, theCryptoFirewall optionally tests whether the result of the transformationis valid for writing at the address specified at step 960 to preventattackers from inappropriately modifying values in the protected memory.This check is primarily required to prevent over-writing of CHIP_KEYvalues stored in updateable memory. (For example, before allowing awrite to the CHIP_KEY, the CryptoFirewall can verify that the result ofthe pseudoasymmetric transformation has a predefined characteristic—forexample, that its first 56 bits equal “10” repeated 28 times.)Alternatively or in addition, the CryptoFirewall should verify that thedestination address value is appropriate (e.g., not pointing to theCHIP_KEY). If the CryptoFirewall determines at step 970 that the writeis authorized, it performs the write at step 980.

[0105] The embodiment of FIG. 9 has the advantage of being very simple,and hence relatively easy to implement and test, but relegates somesecurity tasks (particularly tracking of post-paid purchases) to theICP. As a result, attackers who compromise the ICP could tamper withpost-payment auditing. As noted, the risk of such attacks can bemitigated by requiring the presence of a prepaid rights key to accesspost-paid content. This prepaid rights key can be updated when anon-line audit completes successfully, thereby preventing devices thathave not been audited recently from accessing post-paid content. (Usinga “hacked” CRU to perform an audit is relatively risky, particularly ifaudits suggesting illegal activity can be traced back to specific usersthrough Internet IP addresses, Caller ID/ANI, etc. As a result, theactual and perceived risk can be high enough that attacks on thepost-payment audit data will not present a serious piracy threat.)

[0106] With a modest addition of complexity, the FIG. 9 architecture canbe expanded to include support for post-payment purchases. At step 940,the CryptoFirewall checks whether the address points to the uniquechip-specific key or a post-payment authorization key. If neither,processing continues at step 950, as shown. Otherwise, step 960 isperformed normally then step 970 is performed as follows:

[0107] (a) If the key loaded at step 910 is the post-paymentauthorization key then the CryptoFirewall tests whether the addressreceived at step 960 corresponds to an empty post-paid rights slot. Ifit does, the transformation result is written at step 980. (Thiscorresponds to a normal addition of a post-paid rights key.) Otherwise,if the address does not correspond to a post-paid rights slot or if theslot is not empty, no write is performed.

[0108] (b) If the key loaded at step 910 is the chip-specific key ANDthe address received at step 960 corresponds to a prepaid rights slot,then the transformation result is written. (This corresponds to a normaladdition of a pre-paid rights key.) The CryptoFirewall can optionallyallow replacement of the post-payment authorization key as well (i.e.,if the address received at step 960 corresponds to the post-paymentauthorization key).

[0109] (c) If the key loaded at step 910 is the chip-specific key ANDthe address received at step 960 corresponds to a post-paid rights slot,then the CryptoFirewall tests whether the transformation result fromstep 930 matches the value of the post-paid rights slot. If there is amatch, the memory slot is cleared. Otherwise, no write is performed.

[0110] Post-paid rights slots can be designated as empty if all bits arecleared (or set). In this case, the update processes used in (b) and (c)above require only writing (or clearing) bits in the protected memory.If the protected memory uses a technology such as EEPROM where bitclearing and bit setting operations are performed separately, thepost-payment addition process can be implemented so that purchasing andclearing each use one type of bit operation.

[0111] To audit post-paid purchases, the content provider can (forexample) use the standard key generation process and provide a randomchallenge for the data block at step 920. The output from step 950 iscompared with expected values for post-paid purchase keys to identifythe key in the protected memory. (Alternatively or in addition, purchasedata can be obtained from the ICP or additional logic can be provided inthe CryptoFirewall for audits.) Because the audit clearing process issecured using a chip-specific key, attacks that modify audit data willhave limited effectiveness. In particular, audit records will only becleared if the content provider has correct audit data. As a result, thenumber of purchases that can be performed without paying is limited bythe number of post-payment audit record slots in the CryptoFirewall. Forrisk management, the content provider can initially ship CRUs with onlya few empty slots, then gradually clear slots as customers establishtheir trustworthiness.

[0112] Another Exemplary Simplifled Architecture

[0113] This section outlines a simplified CryptoFirewall architecturethat only provides security for pre-paid content purchases. Thisembodiment has the advantage of being able to use volatile memoryinstead of writeable nonvolatile memory behind the CryptoFirewall.Because volatile memory is often easier to implement (e.g., because onlystandard logic components are required), manufacturing and design costscan be reduced.

[0114] Embodiments invention that use only volatile memory requireaccess to a unique parameter that cannot be replaced by attackers. Thisunique parameter is preferably embedded into the circuit, for exampleusing ROM or blown fuses. Techniques for embedding unique parameters inchips are known in the background art. For example, U.S. Pat. No.5,799,080 to Padmanabhan et al. describes techniques for embeddingserial numbers and cryptographic keys in integrated circuits.

[0115]FIG. 10 shows an exemplary CryptoFirewall embodiment using a small(for example, 64-bit) volatile protected memory and using batch keys tominimize the bandwidth required for REMs. During manufacture (i.e.,prior to the process of FIG. 10), the CryptoFirewall is personalized bypermanently embedding a 64-bit BATCH_KEY and a 6-bit BATCH_OFFSET. Forexample, 64 pairs of fuses may be used to store a 64 bit BATCH_KEY wherethe personalization process blows one fuse of each pair. To ensure thatattackers will not benefit from attacks or manufacturing defects thatonly connect or only blow fuses, self-test logic can be incorporated toensure that exactly one fuse of each pair is blown. (Of course, otherself-test or verification techniques can also be used. Multiple fusescan also be used to help obfuscate the value of the key bits, forexample by making each bit or group of bits the XOR or hash of manyfuses.) It is strongly preferable although not strictly required thatthe combination of BATCH_KEY and BATCH_OFFSET be unique perCryptoFirewall.

[0116] In FIG. 10 at step 1000, the interface control processor (ICP)loads a 64-bit key mask value into an externally-accessible 64-bitregister in the CryptoFirewall.

[0117] At step 1010, the CryptoFirewall verifies that the bit in the keymask corresponding to its BATCH_OFFSET is set. For example, if theCryptoFirewall's embedded BATCH_OFFSET is binary 101110 (46 decimal),the CryptoFirewall will verify that bit 46 of the key mask value is setand, if not, the processing terminates. In an alternate embodiment, theCryptoFirewall sets the bit corresponding to the BATCH_OFFSET if it isnot already set. (Of course, alternate embodiments can use encodingsother than binary “1” for valid, use other testing processes, decrypt orotherwise process the key mask before testing, corrupt the key mask ifthe BATCH_OFFSET bit is not set, use batch offsets that involve multiplebits in the key mask, use multiple key masks, etc.)

[0118] At step 1020, the CryptoFirewall copies the validated key maskvalue from the input register to the CryptoFirewall's protected memory.The CryptoFirewall can optionally perform some cryptographic processingof the value during this copying.

[0119] At step 1030, the ICP loads a 64-bit encrypted rights key intothe CryptoFirewall's externally-accessible register. Under normaloperation, this key corresponds to some content a user wishes to decode.Encrypted rights keys are normally obtained by the ICP from a REM thatwas transmitted by the content provider. Because rights keys may last aconsiderable period of time (e.g., 30 days for a month-long subscriptionto a cable TV channel), encrypted rights key values can be cached (withthe corresponding key mask) in nonvolatile memory external to theCryptoFirewall.

[0120] At step 1040, the CryptoFirewall applies a pseudoasymmetrictransformation to the encrypted rights key. The pseudoasymmetrictransformation is keyed using the XOR of the protected memory contents(i.e., the verified key mask value) and the BATCH_KEY loaded duringmanufacture. The transformation result is stored in the protectedmemory, replacing the key mask.

[0121] At step 1050, the ICP stores an encrypted content decryption keyin the CryptoFirewall's externally-accessible register. The encryptedcontent decryption key is typically obtained from a KDM distributed bythe content provider with the content to be decoded.

[0122] At step 1060, the ICP applies a pseudoasymmetric transformationto the encrypted content decryption key. As in step 1040, thepseudoasymmetric transformation is keyed using the XOR of the protectedmemory contents (i.e., the decrypted rights key) and the BATCH_KEYloaded during manufacture. The transformation result is stored in theexternally-accessible register, where it can be read by the ICP at step1070 and used to decode the content.

[0123]FIG. 11 diagrams the same content decryption key computationprocess. Key mask 1100 identifies which CryptoFirewalls in a batch areauthorized to decrypt an encrypted rights key 1125. (Encrypted rightskeys are distributed with an associated key mask.) The key mask ischecked by key mask validator 1105, which verifies that theCryptoFirewall is among the authorized devices in the batch as specifiedby the key mask. If valid, a representation of key mask 1100 is storedin protected memory 1110. (If it is invalid, the value is not stored orit is stored in corrupted form.) Combination logic 1115 XORs (orotherwise combines) protected memory contents 1110 with BATCH_KEY 1120and provides the result as a key to pseudoasymmetric function 1130.

[0124] The data input to pseudoasymmetric transformation 1130 isencrypted rights key 1125, which is transformed and the result is storedin protected memory 1135 (which is the same as protected memory 1110).Combination logic 1140 optionally combines BATCH_KEY 1145 (which is thesame as BATCH_KEY 1120) with the protected memory contents and providesthe result as a key to pseudoasymmetric transformation 1155. Combinationlogic 1140 is optional; for example, the output of pseudoasymmetrictransformation 1130 can be used directly to key transformation 1155.Note that transformation 1155 does not need to be invertable. Forexample, a keyed hash function such as HMAC can be used instead of apseudoasymmetric function.

[0125] Encrypted content decryption key 1150 is transformed bypseudoasymmetric transformation 1155, yielding content decryption key1160. (In an alternate embodiment where the CryptoFirewall directlydecrypts the content itself, the content itself or a portion of thecontent may be supplied instead of encrypted content decryption key1150.) Note that further processing on the content decryption key 1160can be performed (e.g., by the ICP, playback device, etc.) before theactual content decryption is performed.

[0126] To ensure that operations are performed in the correct order, theCryptoFirewall should keep track of the current state in the transactionprocessing. For example, the CryptoFirewall should not allow reading ofany results until it has completed processing.

[0127] To distribute a rights key, the content provider first choosesthe value of the rights key and identifies one or more CRUs in a batchthat will be authorized receive the key. Next, the content providerconstructs a key mask by setting the bits corresponding to theauthorized CRUs' BATCH_OFFSET values. From the mask and the BATCH_KEY,the content provider can assemble the output of logic 1115. Using theinverse of pseudoasymmetric transformation 1130 (e.g., as prepared bythe PAFG) with the output of logic 1115 as the key, the content providercan compute encrypted rights key 1125 for distribution.

[0128] If bandwidth for key distribution is not limited, the batch keycapability included in FIGS. 10 and 11 is not required. Instead,device-specific keys can be used and (for example) supplied directlyinto the pseudoasymmetric transformation in FIG. 10 at step 1040. As aresult, the CryptoFirewall is somewhat simpler but separate encryptedrights keys need to be distributed for each user. CryptoFirewallarchitectures can also include both device-specific keys and sharedkeys.

[0129] The architecture of FIGS. 10 and 11 prevents a variety of attacksthat involve submitting key masks and/or encrypted rights keys tounauthorized CRUs. For example, if the key mask value is modified in anyway (e.g., by setting the bit for an unauthorized CryptoFirewall in thebatch), the input to pseudoasymmetric transformation 1130 will bemodified, preventing the correct decryption of encrypted rights key1125. Similarly, if an encrypted rights key from a different batch issubmitted, the rights key will also fail to decrypt correctly.

[0130] Many variant embodiments are possible. For example, othercombination processes (such as encryption, pseudoasymmetrictransformations, modular addition, etc.) can be substituted for XORlogic 1115 or logic 1140 in FIG. 11. Combination function 1115 can beomitted altogether or replaced with concatenation if pseudoasymmetrictransformation 1140 takes a large enough key. Specified parameter sizesare exemplary. For example, 160-bit keys can be used to provide bettersecurity than 64-bit keys against some attacks. Larger key mask sizescan increase efficiency of bandwidth use. Operations can be reorderedand additional transformations can be added. (Additional variations aredescribed below in the section entitled “Variations”.)

[0131] Physical Implementations

[0132] The physical implementation of the CRU can have several forms. Apreferred implementation involves combining the interface controlprocessor (as well as its memory) with the CryptoFirewall and protectedmemory on a single chip, which is then placed in a smartcard or PCMCIAcard (PC card). Because the CryptoFirewall security model does notassume that the interface control processor (ICP) is completely secure,the CryptoFirewall should be implemented in hardware separate from theICP, for example as a separate circuit on the same integrated circuit.

[0133] The protected memory used by the CryptoFirewall can be separatefrom, or part of, nonvolatile and/or volatile memory accessible by theICU. If the CryptoFirewall and ICP share memory regions, theCryptoFirewall is responsible for ensuring that the ICP cannotinappropriately access the protected memory without the requiredcryptographic transformations. In particular, the CryptoFirewall shouldintercept and process accesses to protected regions while allowing otheraccesses to pass through it.

[0134] The CryptoFirewall architecture can be combined with hardware andchip card security features known in the background art. For example,detectors can be included to reset the device if unusual operatingconditions (such as high/low operating voltage, high/low temperature,high/low/irregular clock signals, radiation, etc.) are encountered.Tamper-resistant coatings, chip obfuscation techniques, conventionalmemory encryption techniques, error detection/correction logic,intrusion detectors, etc. can also be used. If potential attacks aredetected, the CryptoFirewall can (for example) erase any internalregisters, reset itself, reset the ICP, and optionally even erase theprotected memory.

[0135] The CryptoFirewall may be implemented using dedicated hardware(discrete logic) or using a separate microprocessor. In one preferredembodiment, two microprocessors (each with its own RAM, ROM, and EEPROM)are integrated onto a single chip, which is then embedded in smartcardpackaging. One microprocessor serves as the ICP and communicates withthe second microprocessor which is the CryptoFirewall. Although adual-microprocessor CRU is somewhat more expensive to manufacture thanthe single-microprocessor CRUs in use today, it has the importantadvantage that the inner microprocessor (CryptoFirewall) is shieldedfrom many attacks by the outer microprocessor.

[0136] The clock signal used to drive the CryptoFirewall can be takenfrom (or derived from) an external clock interface, generatedinternally, or supplied by the ICP. If present, clocks derivedinternally by the EEPROM circuit for timing write operations can also beused. External clocks should be used with caution to ensure thatdisruptions in the clock signal will not cause computation errors thatcould be used to attack the circuit. Clock dividers and multipliers canalso be used.

[0137] The CRU can be implemented in a wide variety of forms. Forexample, components 210, 270, 280, and 225 in FIG. 2 can be physicallylocated in the same unit or can be individual components thatcommunicate with each other. The entire CRU can be implemented in asingle chip or using multiple chips enclosed in a tamper-resistantpackaging. (Single chips themselves are sufficiently tamper resistantfor many systems, although features such as tamper resistant coatingscan be included if desired.)

[0138] In one preferred embodiment, the entire CRU is implemented in asingle smartcard. Alternatively, the CRU can be a PCMCIA card. The CRUcan also be a part of the playback device and can be integrated withother portions of the playback system such as bulk decryption, contentdecompression, and/or output. For security reasons, the CryptoFirewallneeds to be an independent circuit from the interface control processor,but can have any form (e.g., a hard-wired circuit, an independentmicroprocessor, etc.)

[0139] The CRU can be integrated into the playback device, providing thebenefit of making it more difficult for attackers to capture or insertcontent decryption keys exchanged between the playback device and theCRU. As a result, some key redistribution attacks can be prevented. (Forcontent whose value is not time-sensitive or for systems operating injurisdictions where anti-piracy laws are unavailable or unenforced, suchattacks are of particular concern. Key redistribution attacks may alsobecome more dangerous as computer networks such as the Internet canprovide attackers with new methods for redistributing keys.) Physicalintegration of the CRU with the playback device has the disadvantage ofmaking it more difficult to replace the CRU if an attack does occur.Alternatively or in addition, the content provider can withhold keyderivation messages until they are actually required by the playbackdevice to minimize the amount of time available for attackers toredistribute keys. Playback devices can also halt if keys are notreceived in a timely fashion.

[0140] Preparing Content

[0141] Digital content is usually distributed in compressed form.Processes for creating, formatting, and compressing content of differenttypes are well known in the background art. In most situations, contentis encrypted after it is compressed, since encrypted material does notcompress well. Occasionally, however, compression and encryption arecombined or simple encryption is applied before compression.

[0142] The key(s) used to encrypt the content are carried in thecontent's KDMs, which are secured with rights keys distributed in REMssent to authorized users. KDMs can specify combinations of rights keysrequired to access content. For example, if two rights keys should berequired to access a particular block of content, the content providercan first generate an encrypted key block (e.g., corresponding toencrypted content decryption key 1150 in FIG. 11). The content providerthen constructs a KDM instructing the ICP to (for example) process theencrypted content decryption key twice (each time using the processdescribed with respect to FIG. 10) and combine the results (e.g., byXORing them together) to produce the decrypted content decryption key.The content provider also computes the content decryption key and usesit to encrypt the content. Next, the content provider typicallyassociates KDMs with the content, for example by interspersing KDMs atappropriate places in the content or by making other arrangements forthe KDMs to be communicated to playback devices. REMs can also be addedif they are distributed with the content. Finally, the content is sentto end users.

[0143] In an alternative embodiment, the content provider can begin byselecting a content decryption key. This key may be (but is not requiredto be) random. The content provider then uses the inverse of theCryptoFirewall pseudoasymmetric function to encrypt the contentdecryption key with a first rights key. If a second rights key is alsorequired to access the content, the content provider can then use asecond rights key to encrypt the content decryption key. The contentprovider then packages the encrypted CDK into a KDM for distribution andencrypts the content.

[0144] Content providers can also broadcast “fixup” values in KDMs thatcan enable CRUs with any of several rights keys to decode the content.In such cases, the ICP typically locates the address of a valid rightskey, uses the CryptoFirewall to process an encrypted rights key, andXORs (or otherwise combines) the CryptoFirewall result with the keyfixup value to derive the actual content decryption key. For example, ifany of three rights keys (K1, K2, and K3) should allow access to somecontent and the CryptoFirewall key derivation process is denotedF(K_(i),X) where X is a data block and K_(i) is a BLOCK_KEY, the contentprovider can choose F(K₁,X) as the content decryption key. The KDM canthen include F(K₁,X) XOR F(K₂, X) to enable CRUs with only K₂ to derivethe content decryption key. Similarly, including F(K₁,X) XOR F(K₃, X)allows CRUs with K₃ to decode the content. This “either/or” rights keyselection operation can be combined with the “and” operation describedabove to allow the content provider to establish sophisticated rules asto which CRUs can decode content. Fixups can also be used to producecompatibility between CRUs of different types (e.g., during periodswhere CRUs are being replaced and two versions are supported). Becausethe key combination rules are secured cryptographically, the KDM parsingand key construction processes can be implemented in the ICP.

[0145] It is possible (and often advantageous) to change contentdecryption keys frequently, for example by requiring a new KDM and a newkey for each one-second or one-minute block of content. If desired,blocks can be protected with different combinations of rights keys. Toreduce the latency experienced by users when they begin to decode somecontent, the content provider can make key changes coincide with placeswhere the decompression algorithm can resynchronize. For example, withMPEG-2 compressed video, key changes can be made to coincide with Ipictures.

[0146] Comments and Considerations

[0147] Under the architecture outlined in FIG. 2, the system remainsrobust even if the ICP and its RAM, ROM, and EEPROM are compromised.This is an extremely important feature of the present design, sincethese components of a chip are particularly vulnerable to both invasiveand non-invasive attacks. The CryptoFirewall controls the addition ofrights keys to the protected memory and thereby prevents informationobtained from one CRU from providing attackers with the ability to addrights keys to other CRUs without breaking the cryptography orperforming an invasive attack. Even if rights keys are compromised,attackers cannot insert them behind the CryptoFirewall.

[0148] In order to compromise the system, the attacker must do one oftwo things: either duplicate the functionality of the CryptoFirewall'spseudoasymmetric transformation or gain the ability to use a CRU'sCryptoFirewall for unauthorized purposes. The former attack iseffectively prevented by making it difficult to reverse engineer therandomized transformation circuit. In addition, for large deployments,groups of CRUs can contain different pseudoasymmetric functions toreduce the consequences of a successful reverse engineering attack. Useof group-specific keys (such as BATCH_KEY values) to broadcast periodicrights keys (such as hourly or daily keys) can also reduce theconsequences of many reverse engineering attacks.

[0149] If the CryptoFirewall is implemented properly, aphysically-invasive attack should be required to gain unauthorizedcontrol over the protected memory. If the CRU is implemented as asingle-chip device (such as a smartcard) with reasonable physicalsecurity measures, physically-invasive attacks pose relatively littlerisk of being performed on a large number of devices because, even aftersuch an attack has been identified, attackers still have to perform thetime-consuming and expensive process of decapping, modifying, andremounting each target chip. These techniques also require expensiveequipment and have a fairly high chance of damaging the target chip. Asa result, most systems will not experience significant amounts of piracyeven if attackers discover a physically-invasive attack that breachesthe CryptoFirewall.

[0150] The architecture does assume that some devices will be attackedinvasively, and therefore minimizes the usefulness of the keys and otherdata that could be obtained. In particular, a physically invasive attackwill potentially provide an attacker with the ability to read fromand/or write to the protected memory of the compromised device. Embeddedkeys (such as BATCH_KEY or BATCH_OFFSET) could be read and/or modified.Simply reading the protected memory contents provides no particularvalue, since the keys stored in the memory are not useful without thealgorithms implemented in the cryptographic unit. The ability to writeto the memory can, however, enable some significant attacks, since itthen becomes possible for the attacker to delete post-payment records,insert new authorization keys, or modify batch offsets. Aproperly-functioning CryptoFirewall is still required, however, toprocess these values into content decryption keys. As a result, theattacker's work modifying one chip can yield one fully-functional piratedevice, but should not lead to a general attack that can be marketed ona wide scale.

[0151] Variations

[0152] This section presents several examples of modified embodiments,and other variants will be evident to one of ordinary skill in the art.

[0153] The technologies disclosed herein may be used in conjunction withother content protection mechanisms. Content can be watermarked to tracecompromises, identify copyright owners, etc. Non-cryptographic securitymeasures can be added in the CRU, playback device, etc. and can help byincreasing the effort required for an attack. Tamper evidence (inaddition to tamper resistance) in the CRU can help to discourage attacksand prosecute pirates.

[0154] In addition to providing a “positive” benefit of adding rights,REMs can also have negative effects such as disabling a CRU by deletingor corrupting a rights key. Such negative effects can be implemented bythe ICP and/or by the CryptoFirewall. To prevent attackers from blockingall REMs, the content provider can combine KDMs and REMs or make themindistinguishable (e.g., by encrypting them).

[0155] Data blocks in KDMs (e.g., such as the data block received by theCryptoFirewall in FIG. 9 at step 920) can have additional meaning to theICP or CryptoFirewall, such as a code update or self-check. The contentprovider can also specify to the ICP that it should supply a portion ofthe ICP's nonvolatile memory as the encrypted CDK or specify othermethods for deriving such values. If KDMs do not need to carry newinformation from the content provider, they can be generated by the CRU,playback device, etc. For example, a timer can be used to generateunique values for the data block used for content decryption.(Implementers of such embodiments may need to be careful, however, toprevent attackers from generating and distributing content decryptionkeys before the content is actually broadcast.)

[0156] The process performed to derive the content decryption key caninclude multiple rights keys and/or transformations. For example,multiple iterations of the process shown in FIG. 5 can be performed andthe results can be XORed, added, concatenated, hashed, or otherwisecombined. (The ICP can manage this process.) The output from a firstiteration can be used as the input to subsequent iteration(s).

[0157] A content provider can, for example, require that CRUs containmultiple rights keys to access some content. For example, a block ofcontent might require a general rights key that is updated frequently(e.g., hourly), a stream-specific rights key, a post-payment purchaseauthorization key, a post-payment audit key (indicating that asuccessful audit was performed recently), a region key (to enforcesports programming blackouts or other geographic restrictions), and/or apremium service rights key.

[0158] The ICP can be involved in cryptographic computations. Forsophisticated KDMs, the ICP can identify and extract the componentsusable by the CryptoFirewall, manage I/O with the playback device andCryptoFirewall, and combine results to produce valid content decryptionkeys. The ICP can also perform additional cryptographic processing onREMs and/or CDKs. Although the CryptoFirewall may be designed with theassumption that the ICP is not a trusted part of the system, it does notcause any harm to also include security in the ICP so that attackerswill not succeed unless they compromise both. Some security-relatedoperations (such as local blackouts of sporting events) are relativelyunlikely to be the focus of concerted attacks and are difficult toimplement in dedicated circuitry, and therefore can be performed by theICP.

[0159] Not all data needs to be protected to the maximum possible levelof security. Occasional deletions, for example, are usually sufficientlyirritating to prevent attacks that do not decode all of the content.Because compression techniques can make even single bit errors disruptplayback, strong protection over just a few percent (or less) of thetotal content can be sufficient. As a result, adequate security canoften be obtained despite challenging bandwidth or performance limits onthe CRU or decryption system. Different portions of the content can alsouse different levels of protection. For example, relatively weaksecurity can be applied to most of the content but much strongerprotection can be applied to a small fraction of the material.

[0160] Content providers should change rights keys periodically toensure that users who have lost their authorization cannot accesscontent. For example, if a user terminates a subscription, the CRU maycontinue to operate unless the rights key is deleted/disabled ormechanisms outside the CryptoFirewall disable access. Content providerscan limit the maximum duration of such use by making rights keys expireperiodically (e.g., hourly, daily, weekly, monthly, annually, etc.) Toensure that key changeovers do not disrupt legitimate viewers, newrights keys can be distributed before the old ones are discontinued.During the changeover period, content can also be broadcast with KDMsthat can operate using both the old rights key and the new one. Anadditional option is to queue the REM that updates the key until the keychange is required. (Such queuing can be done by the playback device,ICP, etc.)

[0161] The memory technology used for nonvolatile protected memory doesnot need to be conventional EEPROM. For example, PROM, flash memory,battery-backed RAM, FeRAM, etc. all provide nonvolatile storage.Embodiments can even use hard drives or other media-based storagesystems, although such approaches are generally infeasible due to theirhigh cost and the difficulty of adding sufficient physical security.(Variants where a hard drive, or a portion of the hard drive, isprotected can be useful in environments where the data itself must bestored and protected in the CRU.) Volatile protected memory can also beimplemented using a variety of techniques, including registersimplemented using standard logic, SRAM, DRAM, etc.

[0162] Although it is strongly preferable that values stored in theprotected memory be cryptographic keys of sufficient length and qualityto prevent attacks such as exhaustive search, it is possible to storeshorter values. In one extreme case, individual bit flags thatcorrespond to access rights can be stored in the protected memory. ValidREMs cause the CryptoFirewall to set and/or clear rights bits in theprotected memory. When producing content decryption keys, theCryptoFirewall tests the value(s) of rights bits (or incorporates thesebit values in the cryptographic transformations) so that valid contentdecryption keys are only produced if the appropriate bit(s) are set.Such embodiments, although possible, involve more risk because invasiveattacks will tend to have more severe consequences.

[0163] The components of the CRU do not need to be connected by a bus.In fact, eliminating the bus and directly connecting components can havethe advantage of increasing the effort required for physically-invasiveattacks as buses can be attacked using (for example) microprobingtechniques.

[0164] CRUs can contain any number of batch keys or device keys. Also,batch keys do not need to be assigned sequentially during themanufacturing process. (In fact, shuffling key assignment can bebeneficial to make it more difficult for attackers to obtain cards withidentical batch keys.) Batch keys (and other keys) also do not need tobe static; they can be replaced or updated using, for example, a keyupdate process such as the one described with respect to FIG. 7. Byincluding keys for multiple independent batches in each CRU, theconsequences of an attack against a single CRU (or small number of CRUs)can be minimized since future REMs and KDMs can be protected using keysthat were not in the compromised device(s). If a clone is produced, itis possible to replace legitimate cards in the compromised device'sbatch then discontinue sending REMs for that batch.

[0165] Techniques such as those described in “Tracing Traitors” by BennyChor, Amos Fiat, and Moni Maor (Advances in Cryptology-Crypto '94,Springer-Verlag, August 1994, pp. 257-270) can be used to identify thesource of rebroadcast keys. The CRU can also encrypt content decryptionkeys, for example using an RSA public key corresponding to the playbackdevice's private key or, preferably, using a unique symmetric key sharedbetween the CRU and the playback device added during manufacturing. Suchtechniques can help prevent key redistribution attacks that involveusing keys produced by one CRU in many playback devices. If the CRU hassufficient I/O bandwidth and computational speed, it can decode thecontent itself.

[0166] The pseudoasymmetric transformations can be implemented using (orreplaced with) a variety of cryptographic operations. Methods forbuilding randomly-constructed logic operations are described withrespect to FIG. 8, but other constructions can be used instead. Forexample, standard algorithms (such as Triple DES), one-way hashoperations, etc. can be substituted. It is also possible to use acombination of functions, such as Triple DES with randomized pre- and/orpost-processing to ensure that the cryptographic security isdemonstrably as robust as Triple DES. Pseudoasymmetric functions canalso be replaced by true asymmetric functions, which can provide bettersecurity but require longer messages and take larger circuits toimplement (e.g., increasing the cost of the CryptoFirewall).

[0167] Although it is generally simplest to have the interface controlprocessor determine which memory addresses to use when storing and usingrights keys, addresses can also be chosen by the CryptoFirewall, by thecontent provider, by the playback device, etc.

[0168] If errors occur in the CRU or CryptoFirewall, a failure countercan be incremented and, if the failure counter reaches a thresholdvalue, the CRU may trigger an audit or cease to work. Examples offailures include torn operations (i.e., where processing is interrupted,for example due to a power loss), invalid commands (e.g., where invalidaddresses are supplied), attempts to perform excessive numbers oftransactions, and incorrect cryptographic parameters (such as failedattempts to clear post-payment audit records).

[0169] Communication processes do not need to be real-time. For example,an auditing process can work as follows: The CRU first receives amessage broadcast with some content that initiates an audit. The CRUthen outputs audit data to the playback device, which queues the data.Next, the playback device sends the audit data to the content provider,for example by broadcasting it using low-speed radio communication.After verifying the audit data, the content provider finally sendspost-payment clearing commands with new content broadcasts.

[0170] Some steps, such as address verification by the CryptoFirewall,are recommended but may be omitted as they are not always essential.Steps can also be substituted with other operations that arefunctionally similar. For example, address verification can be performedby forcing invalid addresses to valid values (e.g., by setting orclearing bits in the address to ensure that the address is in a properrange and aligned appropriately). Many steps can also be reordered. Forexample, the chip-specific portion of the computation described withrespect to FIG. 7 can be XORed with the BATCH_KEY computation resultinstead of with the BATCH_KEY computation input. Many other such simplevariants will be evident to one of ordinary skill in the art.

[0171] The pseudoasymmetric function generator (and functions itproduces) can be used in applications other than content distribution.For example, stored value cards, electronic transit passes, softwarecopy protection, challenge-response authentication tokens, and otherapplications where low-cost devices must carry secrets can all benefitfrom secure cryptographic transformation circuits that are difficult toreverse engineer.

[0172] The CryptoFirewall can include multiple cryptographic algorithms,some of which can be specific to a given CryptoFirewall or batch, andothers that are more general. For example, in a large system with 25million CRUs, it may be advantageous to minimize the consequences if anyindividual CryptoFirewall is reverse engineered. As a result, groups of(for example) 100,000 CryptoFirewalls may be constructed with differentalgorithms. KDMs and/or REMs are transmitted separately to each of the250 groups.

[0173] Any components that include microprocessors can receive codeupdates. For example, code in the playback device, ICP, or theCryptoFirewall can be updated by the content provider. Code updatesshould be cryptographically protected (e.g., with digital signatures,MACs, etc.)

[0174] To ensure that interrupted memory updates do not compromisesecurity, the CryptoFirewall can store memory update data and addressesin a pending-write buffer, set a write-pending bit, perform the write,then clear the write-pending bit. If the write operation is interrupted(e.g., due to a loss of power), the write will either be lost completelyor can be completed from the pending buffer when the device is reset.Write operations can be verified to detect errors. Checksums or otherverification fields can be included in stored data to detect memorycorruption.

[0175] All of the foregoing illustrates exemplary embodiments andapplications, from which related variations, enhancements andmodifications will be apparent without departing from the spirit andscope of this patent. Therefore, the rights under this patent should notbe limited to the foregoing disclosure, but rather construed by theclaims appended hereto.

We claim:
 1. A method for using a removable cryptographic module toenable a second device to obtain secure access to encrypted compresseddigital video content, comprising: (a) receiving a rights enablementdatum and a key derivation datum into said removable cryptographicmodule, where (i) said rights enablement datum includes an encryptedrepresentation of a key enabling decryption of said key derivationdatum, and (ii) said key derivation datum includes an encryptedrepresentation of a key enabling said second device to decrypt saidencrypted content; (b) said cryptographic module transforming saidrights enablement datum, using a key stored in said cryptographicmodule, to determine said key enabling decryption of said key derivationdatum; (c) said cryptographic module transforming said key derivationdatum, using said key enabling decryption of said key derivation datum,to determine an initial content decryption key; (d) said cryptographicmodule re-encrypting said initial content decryption key to produce are-encrypted content decryption key datum, where: (i) said re-encryptedkey datum enables said second device to decrypt said encryptedcompressed digital video content, and (ii) said re-encrypting is securedby a public key corresponding to said second device; and (e)transmitting said re-encrypted content decryption key datum to saidsecond device.
 2. The method of claim 1 where said re-encryptionincludes directly encrypting said initial content decryption key usingsaid public key.
 3. The method of claim 1 further comprising: (i) saidsecond device transforming said re-encrypted content decryption keydatum to determine a key for decrypting said content; and (ii) saidsecond device decrypting said content.
 4. The method of claim 3 furthercomprising said second device uncompressing said decrypted content. 5.The method of claim 3 where said transforming said re-encrypted contentdecryption key includes: (i) decrypting said re-encrypted contentdecryption key to recover said initial content decryption key; (ii)computing an exclusive OR of (A) said initial content decryption key and(B) an additional secret parameter; and (iii) using a result of saidexclusive OR operation as a key to decrypt said content.
 6. The methodof claim 5 where said removable cryptographic module is a smart card. 7.The method of claim 5 where said decrypting said re-encrypted key isperformed using a RSA public key cryptosystem.
 8. The method of claim 1where said transforming said rights enablement datum includes using asymmetric block cipher to decrypt at least a portion of said rightsenablement datum.
 9. The method of claim 8 where said cryptographicmodule includes randomized hardware logic for a pseudoasymmetrictransformation, and where said symmetric block cipher computationincludes said randomized hardware transformation.
 10. The method ofclaim 1 where said removable cryptographic module is a smart card.
 11. Aremovable cryptographic device for enabling at least a second device toobtain secure access to encrypted compressed digital video content,comprising: (a) a nonvolatile memory; (b) a key stored in saidnonvolatile memory; (c) cryptographic logic configured to use saidstored key to transform a rights enablement datum to determine a secondkey, where said second key enables decryption of a key derivation datum;(d) cryptographic logic configured to use said second key to transform akey derivation datum to determine an initial content decryption key; (e)cryptographic logic configured to re-encrypt said initial contentdecryption key in a manner secured using a public key corresponding tosaid second device; and (f) an interface for communicating with saidsecond device, configured to transmit said re-encrypted initial contentdecryption key to said second device.
 12. The device of claim 11configured as a smart card connectable to said second device.
 13. Thedevice of claim 12 where said second device includes: (i) an interfacefor receiving said encrypted compressed video content; (ii) a smart cardinterface for communicating with said cryptographic device, configuredto receive said re-encrypted initial content decryption key; (iii)high-speed decryption logic configured to decrypt said content using akey derived from said re-encrypted initial content decryption key; and(iv) video decompression logic configured to decompress said decryptedcontent.
 14. The device of claim 13 where said decryption logic isconfigured to decrypt said content using a key computed as an exclusiveOR of (A) a result of decrypting said re-encrypted initial contentdecryption key and (B) at least one additional secret parameter.
 15. Aremovable cryptographic module enabling an associated device to obtainsecure access to encrypted compressed digital video content, comprising:(a) means for receiving a rights enablement datum and a key derivationdatum into said removable cryptographic module; (b) means fortransforming said rights enablement datum, using a key stored in saidcryptographic module, to determine a key enabling decryption of said keyderivation datum; (c) means for transforming said key derivation datum,using said key enabling decryption of said key derivation datum, todetermine an initial content decryption key; (d) means for re-encryptingsaid initial content decryption key to produce a re-encrypted contentdecryption key datum, where: (i) said re-encrypted key datum enablessaid associated device to decrypt said encrypted compressed digitalvideo content, and (ii) said re-encrypting is secured by a public keycorresponding to said associated device; and (e) means for transmittingsaid re-encrypted content decryption key datum to said associateddevice.
 16. The removable cryptographic module of claim 15 where saidmeans for re-encrypting includes means for directly encrypting saidinitial content decryption key using said public key.
 17. The removablecryptographic module of claim 15 further comprising: (i) means, withinsaid associated device, for transforming said re-encrypted contentdecryption key datum to determine a key for decrypting said content; and(ii) means, within said associated device, for decrypting said content.18. The removable cryptographic module of claim 15 where said means fortransforming said rights enablement datum includes means for using asymmetric block cipher to decrypt at least a portion of said rightsenablement datum.
 19. A removable cryptographic device for enabling atleast one associated device to obtain secure access to encryptedcompressed digital video content, comprising: (a) nonvolatile means forstoring a key; (b) means for using said stored key to transform a rightsenablement datum to determine a second key, where said second keyenables decryption of a key derivation datum; (c) means for using saidsecond key to transform a key derivation datum to determine an initialcontent decryption key; (e) means for re-encrypting said initial contentdecryption key in a manner secured using a public key corresponding tosaid associated device; and (f) means for transmitting said re-encryptedinitial content decryption key to said associated device.
 20. The deviceof claim 19 configured as a smart card connectable to said associateddevice.